Use a file (as opposed to a directory) as the Outputs property in MSBuild targets.

Directories have unintuitive file stamp behavior sometimes, which may confuse incremental builds.

* Run both sets of Windows tests (local and remote), and fail afterwards if there
  are test failures. This way we get both test suites executed even if the first
  one fails.
* Create a script for executing the local tests (makes it easier to run locally
  as well).
* Make it possible to use a custom built .NET locally by honoring any DOTNET variable
  instead of blindly setting it (makes it easier to test locally).
* Add a .gitignore for the test configuration file we create to run tests on Windows.
* Some minor code simplifications.

… reuse possible

… reuse possible

…ixes #19028.

If a library references resources, until now we've pre-compile/pre-processed
some of those before embedding them the library. This applies to resources of
the following item groups:

* AtlasTexture
* BundleResource
* Collada
* CoreMLModel
* ImageAsset
* InterfaceDefinition
* SceneKitAsset

However, pre-processing resources as a few problems:

* It requires a native (Xcode) toolchain.
    * This is unfortunate when building from Windows: the current approach is
      that when building a library as a referenced project, the remoting part
      is skipped, so all such resources are just dropped.
    * It also means building on Linux doesn't work.
* It makes it impossible to merge resources with the same name, if we wanted
  to do that.

So I'm adding support for bundling the original resources in library projects.

This is enabled using the MSBuild property `BundleOriginalResources=true`,
which is turned off by default for .NET 8 and turned on by default for .NET 9.

Fixes #19028.

Also enable nullability and fix any issues.

The SceneKitAsset items contains all the resources within a .scnasset directory.
However, we need to pass the .scnasset directory to the native tooling, so we compute
the path to the .scnasset directory, and create a new item for it.

This new item must have the correct LogicalName set, which is accomplished by:

* Not deleting the LogicalName from the original item before using it to compute
  the new item's LogicalName.
* Compute the correct LogicalName for the .scnasset, and actually set it.

This fixes an issue where we'd be unable to detec previously processed SceneKitAsset
items in universal builds, because the files wouldn't located where they should be
on disk.

…Resources targets remotely.

They don't seem to need it.

…resources.

…riginal resources.

XVS doesn't copy it when running remotely, and it's needed.

… idea why it's necessary.